feat(desktop): manage Runtime Host update policy - #3771

Thank you for the review. Both findings were valid on 6cafd6fac and are fixed in the current head f2ca7082c:

• A new setup/update now treats a closing development build as a serialization barrier. It waits for that build to close, then starts a fresh build instead of joining the doomed result.
• The PTY records synchronous exit acknowledgement and passes both hasExited and beforeSignal to the shared process-tree terminator before it acts on the PID.

The focused race tests pass, together with the repository build, typecheck, lint, format checks, and Desktop/UI knip checks. The package CI check has passed; the test check is still running.

感谢审查。这两项问题在 6cafd6fac 上均成立，已在当前 head f2ca7082c 中修复：

• 新的 setup/update 现在会把正在关闭的开发构建视为串行化屏障：等待其关闭完成后启动新构建，不再加入注定失败的旧结果
• PTY 会同步记录退出事实，并在共享进程树终止器按 PID 操作前传入 hasExited 和 beforeSignal 两项防护

相关竞态测试已经通过，全仓 build、typecheck、lint、format 以及 Desktop/UI knip 检查也均通过。package CI 已通过，test 检查仍在运行

Thank you for following up. The remaining window is theoretically real, but after examining the operating-system boundary we do not consider it an actionable P2 blocker for this PR.

The current implementation checks hasExited after asynchronous topology discovery and checks beforeSignal immediately before its first OS action. A wrong target would therefore require all of the following: the original process has already exited in the kernel, the node-pty exit callback has not yet run, the OS has already reused the numeric PID, and the replacement process has become a process-group leader with the same PGID. If any descendant still belongs to the original process group, that PGID remains the group we own and cannot yet be reused.

There is no portable atomic process-incarnation binding for this operation across macOS, Linux, and Windows. ChildProcess.kill() and IPty.kill() ultimately have the same numeric-PID limitation. Adding a process start-time check would still leave a check-to-signal TOCTOU window and would create false assurance; closing it fully would require platform-specific process handles or pidfd support, while process-group cleanup would remain a separate concern.

For that reason, we are retaining the current bounded checks rather than adding non-portable complexity that does not actually close the race. The concrete closing-build race is fixed, and both current CI checks are now green.

感谢继续审查。这里描述的残余窗口在理论上存在，但在检查操作系统边界后，我们认为它不是本 PR 中可合理处理的 P2 阻断问题。

当前实现在异步进程拓扑发现后检查 hasExited，并在首次执行操作系统动作前立即检查 beforeSignal。要误伤其他进程，必须同时满足：原进程已在内核中退出、node-pty 的退出回调尚未执行、操作系统已经复用了该数字 PID，并且新进程恰好成为具有相同 PGID 的进程组 leader。只要原进程组仍有任何后代存在，该 PGID 仍属于我们拥有的进程组，也不能被复用。

macOS、Linux 和 Windows 之间不存在可移植的原子进程代次绑定机制；ChildProcess.kill() 和 IPty.kill() 最终也具有相同的数字 PID 限制。增加进程启动时间校验仍会留下校验到发信号之间的 TOCTOU 窗口，只会形成虚假的安全保证。要完全闭合，需要平台专用的 process handle 或 pidfd，而进程组清理仍然需要单独处理。

因此，我们保留当前有边界的防护，不增加无法真正闭合竞态的非可移植复杂度。实际存在的 development build 关闭竞态已经修复，当前两项 CI 检查也均已通过。